Tech Arsenal 1

home *** CD-ROM | disk | FTP | other *** search

/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-05 / xgate200.zip / XGATE.DOC < prev next >

Wrap

Text File | 1992-11-22 | 51KB | 1,651 lines

+------------------------------------------------------+ | | | | XGATE 2.0 XGATE 2.0 | | | | | | MHS to SMTP Gateway MHS to SMTP Gateway | | | | | | +------------------------------------------------------+ XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Features Features Seamless Interaction Rules-Based No Lookup Tables Low Administration Simple Addressing Intuitive Design High Reliability Written to Handle Exceptions Supports Return Receipts Automatic Uuencoding / Decoding of File Attachments Supports MHS 1.1 through 1.5 (SMF-64, 70) Supports Multiple MHS hosts Cost Effective / Realistically Priced i XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Introduction Introduction XGATE is a reliable, stable, intuitive, and seamless MHS to SMTP gateway. For its inexpensive registration fee, it also gives you the best power-to-dollar ratio of any MHS to SMTP gateway available. Most other MHS to SMTP gateways start at $2,500+, are more cumbersome to setup, more awkward to use, and less adept at doing the job. In addition, they usually want more money for each additional MHS host they might route mail for - or for each user. In a way this seems almost as ridiculously greedy as if Dos cost more money for each file stored on a disk. XGATE reliably bridges the broad worlds of MHS and SMTP with a simple addressing scheme that requires no routing tables, alias tables, user name tables, or any other type of configuration maintenance. Once XGATE is installed and running, new users on both sides have immediate E-Mail access to users on the other side. XGATE will route mail for any number of MHS hubs. Since the address SMTP users use to send mail to MHS users optionally allows the MHS host name to be specified, XGATE will simply pass the fully qualified address through to the MHS host its attached to. XGATE can be run with two different types of SMTP agents: XSMTP - a high-performance internally multi-tasking add-on module which uses the PC/TCP kernel from FTP Software. Charon - a freely copyable SMTP gateway from Clarkson University. Dave Frailey DAC Micro Systems Voice: 800-776-1322 Voice: 805-264-1700 BBS: 805-264-1219 ii XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Shareware Concept (the legal business) Shareware Concept (the legal business) XGATE (including XSMTP) is not, nor has ever been, public domain or free software. XGATE is distributed under the User Supported software concept (Shareware). Non-registered users are granted a limited license to use XGATE for a trial period not to exceed 45 days in order to determine if it suits their needs. Any other use of XGATE, or use past this period, requires registration. All users are granted a limited license to copy XGATE only for the purpose of allowing others to try it, subject to the above restrictions as well as these: 1) XGATE must be distributed in absolutely unmodified form, including ALL program files, documentation files, and other files. 2) XGATE may not be included with any other product for any reason whatsoever without a license from DAC Micro Systems. 3) No charge or payment may be levied or accepted for XGATE (except that recovered for media and operating costs). Bulletin Board system operators may post XGATE on their BBS for downloading without written permission only if the above conditions are met, and only if no special fee is necessary to access the XGATE files (a general fee to access the BBS is acceptable). The unregistered (shareware) version of XGATE automatically tracks how many days have passed since the shareware trial period started. During the first 45 days it will work in a fully functional fashion, as if it were registered. When 45 days expire and you are still using the unregistered version, XGATE will start inserting a warning line in each message that indicates the shareware trial period has expired. Registering XGATE allows you to use this product after the trial period expires for an indefinite period of time. Registered XGATE users will also get mailed notifications when significant updates are available. More importantly though, registered users know they are helping to ensure that high-quality software like XGATE can continue to be developed and distributed in this low-cost manner. For more information on ordering, refer to the REGISTER.DOC text file included with this package. All DAC Micro Systems products are trademarks or registered trademarks of DAC Micro Systems. Other brand and product names are trademarks or registered trademarks of their respective holders. Acknowledgments Acknowledgments Special thanks to Steve Glick of Dallas County Community College District for plenty of valuable beta testing help. iii XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Contents Contents FEATURES.......................................................I INTRODUCTION..................................................II REQUIREMENTS...................................................1 Memory......................................................1 LIMITATIONS....................................................2 CONCEPT OF OPERATION...........................................2 ADDRESSING.....................................................3 SMTP Addressing.............................................3 MHS Addressing..............................................3 The Default SMTP Host.......................................4 OPTIONS........................................................6 Uuencoding..................................................6 Return Receipts.............................................6 Postmaster..................................................8 INSTALLATION...................................................9 Adding a gateway name in MHS...............................10 Variables in XGATE.CFG.....................................11 Using XSETUP...............................................19 iv XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Requirements Requirements The requirements for XGATE change somewhat depending on which SMTP agent it is running with. XGATE always requires its own PC, one that is connected with IPX to your Novell network. If XGATE is running with the XSMTP add-on module, the SMTP mailer becomes a background function of XGATE and runs within the same computer. If XGATE is running with Charon as the SMTP mailer, a separate computer is needed on which to run Charon. Documentation on the particulars of each is included in separate files. XGATE is written 100% in tight and efficient assembly language. But even as such - if you are running XGATE with the XSMTP module, the memory requirements and CPU requirements are a bit higher than if it is running with Charon as the SMTP mailer. When XSMTP is the SMTP mailer running as a background function in XGATE's computer, the computer running XGATE will need a full 640k of memory and having expanded memory (LIM/EMS) 4.0 will definitely help. When Charon is the SMTP mailer running on a different computer, XGATE will do just about as well on a 4Mhz XT as it will on a 66Mhz 486, and only requires approximately 384k of free memory. XGATE automatically adjusts to a color or monochrome monitor. XGATE should work fine with versions of MHS as old as 1.1 (SMF-64). It automatically detects and uses capabilities in MHS versions as new as 1.5 (SMF-70). Memory Memory XGATE automatically detects and uses expanded memory (LIM/EMS) if its version 4.0 or greater. You'll probably never come close to having a problem with free memory if at least 256k of expanded memory is available. 1 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Limitations Limitations XGATE's messaging limitations are more those of MHS than XGATE. XGATE can handle a message of unlimited length. The MHS limit is 64k (ver 1.5) for body text. XGATE can handle an unlimited number of file attachments and automatically uuencode them into an SMTP message. It can also do the reverse with inbound SMTP messages and decode them to multiple MHS attachments. MHS 1.1 however, can only handle one attachment (in this case XGATE only decodes the first file and leaves the rest uuencoded in the message body). MHS 1.5 can handle 64 file attachments, and XGATE will automatically decode and create attachments for as many uuencode blocks that exist in the message body text. Concept of Operation Concept of Operation How does it work? Its not really that complicated.... When run with XSMTP or Charon as the SMTP mailer XGATE takes full advantage of Novell's Queue Services API. On a configurable basis XGATE scans the MHS outbound directory for new mail, converts anything it finds and posts it in the SMTP_OUT job queue for the SMTP mailer to handle. In the same scan cycle it also checks the SMTP_IN job queue, converts any messages in it and posts them in the MHS inbound directory for MHS to route. XGATE uses a "clean-cut" approach to doing business with Novell. When initially run XGATE logs itself in as a job server and attaches to both the SMTP_IN and SMTP_OUT job queues. Anything in the SMTP_IN queue is considered inbound and likewise anything in the SMTP_OUT queue is considered outbound. When XGATE is run with Charon, the XCHARON driver running behind Charon forces it to comply with this simplistic approach. When XGATE is run with XSMTP, more sophisticated queue services are utilized to rotate and reschedule queue jobs. All of this stuff about Novell job servers, job queues, and the appropriate privileges for each, are installed automatically in one easy step using XGATE's setup program (XSETUP). 2 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- ADDRESSING ADDRESSING SMTP Addressing SMTP Addressing So how does a SMTP user send mail to a MHS user? Rather easily. If the fully qualified SMTP host name for XGATE is called "charon.myorg.com", users on SMTP simply send mail to: joe@charon.myorg.com If you have multiple MHS hosts, and the message is intended for a user not on the MHS host connected to the XGATE gateway, SMTP users can include the user's MHS host after the user name as follows: joe.mhs1@charon.myorg.com If the destination MHS user is on the same host as the XGATE gateway, or if MHS is set up to do multi-host workgroups, this should not be necessary. If a MHS user's application name needs to be specified (normally it doesn't since MHS will drop it in their default application), it can also be included in the address by prefixing it with a percent sign. For example: joe%pmail.mhs1@charon.myorg.com MHS Addressing MHS Addressing Under MHS you define a gateway name for XGATE to use. The name of the gateway is akin to the name of another MHS hub. When MHS users send mail through XGATE, they do it the same way as if they are addressing a message to a user on another MHS hub, except that "gateway" information (the actual SMTP address) usually needs to be provided within curly braces. How you address mail to users on another host (or gateway) tends to vary between different e-mail applications (user agents) that run on top of MHS. The native MHS syntax is: user . application @ host {gateway_parameters} 3 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- After-market E-mail applications sometimes transform this syntax into a different form more to their liking. For instance, with DaVinci eMail Ver 1.7 you would send mail as: host "gateway_parameters" [:user] When MHS mail is sent through the XGATE gateway, XGATE normally pays no attention to the user name unless the gateway parameters are not given. (It never pays any attention to an application name if specified.) In order to get the message to XGATE for conversion, a user must specify XGATE's gateway name. The actual SMTP address of the recipient is specified in the gateway parameters. For example, if your MHS gateway name for XGATE is called SMTP, and a user wanted to send a message to "joe@hisorg.com", in the native MHS syntax they would send the message as: @smtp {joe@hisorg.com} Note: Some MHS E-Mail applications won't like not having a user name specified before XGATE's gateway name, in which case a dummy user name before the gateway name will be necessary. For example: email @ smtp {joe@hisorg.com} If your e-mail application is DaVinci ver 1.7, you would send the message as: smtp"joe@hisorg.com" If the sending MHS application does accept an address without a user name specified, an additional side affect is that when MHS routes the message, you won't see any user name on the routing activities screen. To have it be more informative, you could fib to your users and tell them that the SMTP user name is needed in both locations: joe @ smtp {joe@hisorg.com} The Default SMTP Host The Default SMTP Host In XGATE's configuration you can define a default SMTP host. When XGATE processes a message that does not contain a host name in the gateway parameters, XGATE automatically appends the name of the default host to the SMTP address. 4 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- For example, if the default SMTP host is set to "hisorg.com", and you wanted to send a message to "joe@hisorg.com", all you have to say when you address the MHS message is: @smtp {joe} This can be carried a step further if the recipient user's name is eight characters or less because XGATE automatically uses the MHS user name if no gateway parameters are given. For example: joe @ smtp 5 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Options Options Uuencoding Uuencoding If the "uuencode=" option in XGATE.CFG is enabled (or not specified - the default is enabled), XGATE will automatically uuencode and decode MHS file attachments. When uuencoding is on, each message received from SMTP is scanned for uuencoded files. The scanning algorithm is very rigid about assuming the presence of a uuencode block. If any part of the uuencoded block doesn't conform to the specification, uuencode scanning of the SMTP message is abandoned and the message body is passed through untouched. If you are running on MHS 1.5 or greater, multiple uuencoded files may be passed in a single SMTP message and they'll be decoded into separate attachments. If you are running a version of MHS older than 1.5, only the uuencoded file is decoded to an attachment. Any subsequent uuencoded files in the same message will remain in the body text of the message. When a block of uuencoded text is decoded from an inbound SMTP message, the uuencoded block is removed from the message text, but the lines preceding and following the block remain intact. When an outbound MHS message contains an attachment, it is automatically uuencoded. If running on MHS 1.5 or greater and multiple attachments are present, multiple uuencode blocks are built within the outgoing SMTP message. XGATE has no internal limitations on the size of uuencoded files. Return Receipts Return Receipts XGATE can be configured to always ask MHS to generate return receipts when incoming SMTP mail is read by the MHS user, by including the following statement in XGATE.CFG: smtp_receipts=y 6 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- But this switch can only be globally on or off for all inbound SMTP mail. If this switch is disabled, two other methods of getting a return receipt are still available: 1) SMTP users can ask for a return receipt by embedding a flag in the address of the message, which produces the same affect on a case-by-case basis. Normally, a SMTP user addresses a MHS user as follows: user.mhshost@gateway However, an additional "/r" can be appended after the mhshost and XGATE will then ask MHS to generate a return receipt. For example: user.mhshost/r@gateway 2) XGATE always sets the MHS return receipt flag if an inbound SMTP message has a "Return-Receipt-To:" header field. For mail going from MHS to SMTP, return receipts are a little more convoluted. XGATE.CFG has an option, use_mhs_ret_rcpts, which controls whether XGATE will pay any attention to whether an MHS user asked for a return receipt. SMTP was never designed with return receipts in mind though. Some mailers recognize the "Return-Receipt-To" header field and some don't. If a mailer recognizes this field, it usually generates the receipt at time of delivery - not time of reading. If you enable the "use_mhs_ret_rcpts" flag in XGATE.CFG, XGATE will add a "Return- Receipt-To" field in outgoing SMTP headers when MHS messages ask for a return receipt. This option is disabled by default since receipts generated by this header field could be misleading to an MHS user who would expect it to mean a time-of-reading receipt. Another option if the XGATE.CFG use_mhs_ret_rcpts field is disabled is that MHS users can also embed a flag in the SMTP address which will cause XGATE to include the "Return-Receipt-To" field in the SMTP header. Normally, a MHS user addresses a SMTP user as follows: user @ gateway {username@smtphost} However, an additional "/r" can be appended after the username in the SMTP address and XGATE will then include the "Return-Teceipt- To" field in the outgoing SMTP message. For example: 7 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- user @ gateway {username/r@smtphost} Postmaster Postmaster XGATE Automatically re-addresses inbound SMTP mail sent to "Postmaster" to the MHS administrator. When it does so, the first line of the body will include a comment from XGATE indicating that the message was originally addressed to the postmaster. When MHS generates an error notification from -Maiser- (where did they get that name?), XGATE sends the SMTP message as being from Postmaster. 8 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Installation Installation The recommended place to install XGATE is on the local hard drive of the PC from which it will run. You can try installing XGATE on a network volume, but when XGATE terminates it will automatically log itself out from the file server, and the only network drive visible at that point is the SYS:LOGIN directory - which is probably not where you would have installed XGATE. If you really want to run XGATE from a file server volume, whatever process which runs XGATE would have to be capable of logging in under a temporary ID (with read privileges to that directory), map a drive to the directory, change directories, and then run XGATE. Before XGATE logs in as a job server, it first reads all overlays and configuration files. When you run XGATE the current directory must be where XGATE's overlays and configuration file (XGATE.CFG) are located. If you did install XGATE on a file server volume, normal users do not need any disk privileges to XGATE's directory. The generic installation of XGATE consists of three steps: 1. Adding a gateway name in MHS 2. Editing XGATE's configuration file, XGATE.CFG 3. Using XSETUP to build the Novell job servers and queues After you accomplish these steps, you must then refer to the installation instructions for either XSMTP or Charon, depending on which one you're using as XGATE's SMTP agent. 9 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Adding a gateway name in MHS Adding a gateway name in MHS When you tell MHS to add a gateway name, it automatically builds the appropriate directory structure for the gateway under mv\MHS\MAIL\GATES. If you already know how to do this, go ahead and add the gateway name (configure the gateway version as either 64 or 70) - there's nothing more that needs to be done with MHS and you can skip ahead to editing the variables in XGATE.CFG. XGATE doesn't use the normal INPOST or OUTPOST executables, it only needs the directory structure. To add the gateway name under MHS that XGATE will use, you must log into MHS as the MHS administrator and run the Directory Manager. Under the Directory Manager, you then select "routes to workgroups, hosts, and gateways" and from there, pick "Add entry" and then pick "Define a gateway". What you enter for the "Host name:" is the most significant item of information. You might want to keep it short and easy to type. This is the name MHS users will type when they send mail through XGATE (you could of course define another hub which routes via this name if you want to alias it down to a shorter name). Whatever you type for the "Host name:" - remember it and write it down. You will also need to enter it into XGATE's configuration file. What you enter for the "Description:" is purely discretionary. XGATE doesn't use it. Under "Gateway Version:" you can enter either 64 or 70. This tells MHS what level of the SMF language the gateway understands. If set to 70, messages with more than one XGATE recipient will be kept in one file for fan-out by the gateway. Under "Gateway Commands:" don't enter anything. A lot of MHS gateway programs are run directly within MHS and these are the commands that would be passed to the gateway program when executed. Since XGATE runs on a separate PC, gateway commands should be left blank. So all we're really doing is just using MHS to build a new gateway name in its host table and creating the corresponding MHS directory structure. Nothing more. The first time XGATE runs it will automatically build some additional directories under its gateway subdirectory in MHS. But you don't need to worry about doing it yourself. 10 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Variables in XGATE.CFG Variables in XGATE.CFG XGATE is configured by editing a text file called XGATE.CFG with whatever text editor suits your fancy. A sample XGATE configuration file is included with this package. The format (syntax) of the XGATE.CFG file is very loose. You can use spaces, tabs, and the equals sign to delimit variable names from their values. What follows are the descriptions of variables which are generic to XGATE (needed for both XSMTP or Charon modes), listed in the order they appear in the XGATE.CFG configuration file. Variables specific to XSMTP (applicable only if you are using it instead of Charon) are described in XSMTP's separate documentation. If you aren't using XSMTP, XGATE will ignore the XSMTP variables. mhs_path= mhs_path= This variable tells XGATE what directory contains MHS. This path is normally entered using a Novell volume name, not a Dos drive letter. For instance, if MHS is installed in the root directory of SYS: (i.e. the path to the MHS Mail directory is SYS:MHS\MAIL), you would enter "mhs_path=SYS:" (without the quotes). mhs_gateway_name= mhs_gateway_name= This variable tells XGATE what gateway name to scan under MHS, and is also used to build the return address in outgoing SMTP mail. It should contain the same name used when you added the gateway name under MHS. mhs_admin_errors= mhs_admin_errors= This variable tells XGATE whether or not to send the MHS administrator copies of various errors (such as routing or non- delivery) as a message. The possible answers are either Yes or No. 11 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- mhs_administrator= mhs_administrator= This variable overrides XGATE's automatic determination of the MHS administrator. Normally XGATE will determine who the MHS administrator is by reading MHS's NETDIR.TAB file. It can be convenient to override who that user is if a different person administers the SMTP gateway than who the MHS administrator is. The address entered is expressed in native MHS syntax (i.e. mhs_administrator=joe@mhs1). mhs_default_host= mhs_default_host= This variable controls what happens to inbound SMTP mail when it does not contain an MHS host name. If this variable is omitted or left blank, XGATE will route the message to the local MHS hub. If this variable is set, inbound SMTP mail that doesn't contain a MHS hub (host) name will be routed to the value given. This variable is most often used to send inbound SMTP mail without an MHS host name to a workgroup's name instead of the local host's name. use_mhs_total_fields= use_mhs_total_fields= This variable enables an effect similar to the "include_smtp_fields" option above, except that it works a little more cleanly provided your MHS software recognizes the SMF-70 "Total-to:" and "Total-Copies-to:" header fields. If this option is enabled, XGATE will write the "Total-to:" and "Total-Copies- to:" MHS header fields with a complete list of their respective recipients. This keeps the information out of the body text and possibly allows replies to go to all recipients, but only if your MHS E-Mail application works properly with these fields. Possible values are either Yes or No. You probably don't want to enable this option, and "include_smtp_fields" at the same time. include_header= include_header= This variable controls whether the entire header of inbound SMTP messages is passed through in the body text of MHS messages built. Its allowable values are either Yes or No. 12 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- include_smtp_fields= include_smtp_fields= This variable allows some of the SMTP header fields to pass through at the beginning of the body in the MHS message. Sometimes these fields can provide a lot of valuable information to the MHS user which might otherwise be hidden depending on the particular MHS E-Mail software in use. For instance, if a message had multiple recipients (specified by the SMTP To: header field), but the MHS E-Mail software displays the MHS "Send-To:" field instead, the MHS recipient won't see the complete list of recipients. This variable has the following format: include_smtp_fields=[T][F][C][R] Each flag enables the following SMTP header fields: T - To: F - From: C - Cc: R - Reply-To: smtp_gateway_name= smtp_gateway_name= This is the fully qualified host name which you will configure Charon to run as. It is used to build the reply address in outgoing SMTP mail. smtp_default_host= smtp_default_host= This is an optional fully qualified host name which you can use to have mail automatically sent to if the MHS user didn't specify a destination SMTP host. This doesn't have to have anything to do with the relay host you will configure Charon to send all outgoing SMTP mail to. 13 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- smtp_user_suffix= smtp_user_suffix= This is an optional field which normally has no value. If for some reason you need some additional text inserted in a reply address between the user's name and the smtp_gateway_name, this field will do that. XGATE automatically formats the reply address of an outgoing SMTP message as "user.mhshost@smtp_gateway_name". Any text entered by this variable will be inserted between ".mhshost" and "@smtp_gateway_name". This variable is only used when building the reply address of an outgoing SMTP message. smtp_timezone= smtp_timezone= This variable controls what text XGATE appends after the time a message was entered. Normally this is a value such as PST, EST, etc... This variable is only used when building the reply address of an outgoing SMTP message, and only if the date field did not use a Universal Time Coordinate. smtp_exclude_mhs_hub= smtp_exclude_mhs_hub= This variable controls whether outgoing SMTP messages will include the name of the MHS hub from which they originated in the return address. In a single MHS hub environment where XGATE and the only MHS hub are on the same file server, it may not be considered necessary for inbound SMTP messages to include the name of the MHS hub in the reply address, since messages received from SMTP without an MHS hub name are normally routed to the MHS hub from which XGATE runs (unless overridden with MHS_DEFAULT_HOST). Answering yes to this variable might reduce some confusion if you plan to tell SMTP users that MHS users are addressed as "user@smtphost" instead of "user.mhshub@smtphost", since they then won't get messages with the reply address showing the MHS hub as in the second example. 14 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- smtp_receipts= smtp_receipts= This variable controls whether all messages are flagged to produce a return receipt (back to a SMTP user) when XGATE converts a SMTP message to MHS. Possible answers are only Yes or No. Normally this variable isn't turned on. There is a method in XGATE's addressing syntax however for SMTP users to flag they want a return receipt based on how they address the destination MHS user. This was described previously under "Return Receipts". As best I can determine, there is no standard way to cause SMTP user agents to produce time-of-reading return receipts based on something inserted in the SMTP message header. If I am incorrect please let me know. use_mhs_ret_rcpt= use_mhs_ret_rcpt= This variable controls whether XGATE will pay any attention to whether an outbound MHS message has the return receipt flag set. If this variable is enabled and an MHS message requests a return receipt, a "Return-Receipt-To:" header field is inserted in the SMTP header built. In most cases however, any notification returned is only a delivery notification from the SMTP mailer, not a time-of-reading notification. If most MHS users on your system default to having return receipts enabled, it may not be desirable to have this option enabled. It is off by default. uuencode= uuencode= This variable controls whether XGATE will automatically uuencode files attached to MHS messages, and whether it will automatically scan inbound SMTP messages for a block of uuencoded text. Possible answers are either Yes or No. decode_header= decode_header= This variable is provided to help trigger automatic uudecoding of encoded MHS file attachments when they reach a remote SMTP user. A lot of SMTP user agents won't automatically scan for uuencode blocks unless they see a header field in the SMTP message which makes them think the message might have a block of uuencode text. When one or more of these variables are defined in XGATE.CFG, XGATE will automatically insert all of them in the header of the SMTP message when it uuencodes a MHS file attachment. 15 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- The best way to determine whether this field is needed, and what text to use if so, is to scrutinize the header generated by the SMTP user agent in question when it itself uuencodes a file attachment. If the name of the attached file is needed in the SMTP header, embedding a %fn in the variable's definition will expand into the real-time name of the file(s) when the message is built. For example: decode_header=Next-Attachment: %fn decode_header=Content-Type: x-uuencode-apple-single The first example is designed to trip automatic decoding on NEXT computers, and the second for Apple computers running Microsoft Mail. A little experimentation may be necessary to determine whether a remote SMTP user agent can be tricked into automatically decoding a uuencoded block, and what the proper values are. scrap_mhs_attach= scrap_mhs_attach= This variable allows you to specify filenames which are automatically scrapped (discarded) if they appear as an MHS attachment (vice uuencoding them). This is useful with some E- Mail applications which like to always add an attachment containing formatting information (such as Beyond's Windows product) that has no useful purpose if sent across an SMTP gateway. This variable can be defined more than once. For example: scrap_mhs_attach=*BEYOND* ;Scrap Beyond's attachs scan_frequency= scan_frequency= This variable controls how often XGATE will scan for new mail in seconds. XGATE is very efficient about doing this, so a value between 10 and 20 seconds would not impose much of impact on network traffic or file server utilization. 16 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- black_and_white= black_and_white= This variable tells XGATE whether to operate in black and white mode. This could be useful when you have a monitor that displays shades of green (or whatever) attached to a color video card. mute= mute= This variable tells XGATE whether or not the speaker is muted when errors are displayed. Possible answers are either Yes or No. screen_save= screen_save= This variable sets the number of minutes after which XGATE will blank the screen if no activity has occurred. A value of zero disables the screen saver. The screen is automatically un-blanked when new activity occurs. inbound_log= inbound_log= If this variable is given, a complete path and filename must be specified. XGATE will then write a single-line entry in the file for each inbound SMTP message received. If the path points to a server volume (i.e. SYS:XGATE\LOG\INBOUND.LOG), the "Grant Additional Privs" option in XSETUP must be used to give the XGATE job server privileges to the directory. outbound_log= outbound_log= If this variable is given, a complete path and filename must be specified. XGATE will then write a single-line entry in the file for each outbound SMTP message received. If the path points to a server volume (i.e. SYS:XGATE\LOG\INBOUND.LOG), the "Grant Additional Privs" option in XSETUP must be used to give the XGATE job server privileges to the directory. 17 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- error_log= error_log= If this variable is given, a complete path and filename must be specified. XGATE will then write a single-line entry in the file for each error or warning message encountered. If the path points to a server volume (i.e. SYS:XGATE\LOG\INBOUND.LOG), the "Grant Additional Privs" option in XSETUP must be used to give the XGATE job server privileges to the directory. 18 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Using XSETUP Using XSETUP After you've created the MHS gateway name in MHS and edited XGATE's configuration file (XGATE.CFG), the last step to generically configuring XGATE is to use XSETUP to build the Novell job servers and job queues which XGATE uses. Before running XSETUP you must first log in as a supervisor equivalent. If you are initially installing XGATE, simply pick the "Create Server & Queues" option and XSETUP will do the rest. XSETUP can also be used to remove the job servers and job queues, or to grant additional privileges to other network directories for the XGATE job server, if you want XGATE to write log files to a network drive. When you are finished using XSETUP (it doesn't take long), the generic portion of XGATE's installation is complete. You next have to configure either XSMTP or Charon, depending on which you will be using. Their installation and configuration is documented in separate files under their own names. Create Server & Queues Create Server & Queues This option automatically builds and configures all of the Novell- related details XGATE needs. After you pick it, XSETUP will ask you for the Novell path to the MHS directory. If you entered "SYS:" in XGATE's configuration, you would enter the same here. After that, the rest is automatic. During the "Create Server & Queues" process, XSETUP will attempt to create a directory on SYS: called CHARON and grant RWCEMF privileges to that directory for the job server that XCharon will log in as. This directory is intended to provide a place where Charon has full disk privileges, mainly for writing log files. If you are using XGATE's XSMTP module instead of Charon, you can delete the SYS:CHARON directory afterwards. Remove Server & Queues Remove Server & Queues This option completely removes the job servers and job queues that "Create Server & Queues" created in the Novell Bindery. 19 XGATE - MHS to SMTP Gateway ---------------------------------------------------------------------- Grant Additional Privs Grant Additional Privs This option allows you to grant the XGATE job server RWCEMF privileges to additional network directories. Currently the only reason this is needed is if you want XGATE to write its log files to a network directory. 20